Red-teaming the supported examples with subagents found a template injection.
Mutation-testing the acceptance suite found a hole it could not have seen.

Template injection, reachable from a CLI argument

A pipeline's {{ }} expressions are authored with the pipeline. The values
substituted into them are not — they arrive from -i name=value, an inputs
file, or an upstream step's output. Those values are rendered too, which is
deliberate (-i out_dir='{{ base }}/reports' is useful). Jinja's stock
Environment rendered them with Python's object graph in reach:

orchestrator run examples/supported/01_hello_filesystem.yaml \
  -i greeting='{{ "".__class__.__mro__[1].__subclasses__() | length }}'

output/greeting.txt == "1183, world"     exit 0

1183 is the length of __subclasses__() — the first hop of the standard
Jinja sandbox escape, from a plain command-line argument.

Every environment on the execution path is now built by
core/template_sandbox.py and is a SandboxedEnvironment. Three call sites
built a bare Template(...) and bypassed every environment — including the
declared-outputs renderer in orchestrator.py — and now use the same
factory.

TemplateManager.render then swallowed the SecurityError and returned the
payload unrendered, leaving the refusal visible only in a log line. A sandbox
violation now propagates; every other render failure keeps its existing
fallback.

Ordinary expressions, filters and {{ step.result.field }} are unaffected —
the blocking suite is unchanged at 562 passed, and the example catalog still
compiles everything it compiled before.

A step can fail without raising, and nothing tested it

Deleting the reported_failure branch of StepResult.from_task — the branch
catching a tool that returns {"success": false} while its task ends
COMPLETED — left the entire acceptance suite green. 06 fails by raising,
so it never reaches that code.

05_reported_failure.yaml is the sibling that does. The run exits 1 and
reports success=false while no task is FAILED:

before:       status=completed  success=True
read_missing: status=completed  success=False   File not found: ...
after:        status=completed  success=True

Case could not express that either: it assumed status completed implied
success — the same conflation the runtime had. It now carries
reported_failure separately and asserts status and success together.

Evidence

Every new assertion was mutation-tested against un-fixed code:

• Blocking suite 548 → 562 passed, 0 failed
• Examples validating 8/116 → 9/117
• ruff check src/orchestrator (CI rule set) clean; compileall clean

Two red-team claims I could not confirm, and did not act on

• Unresolved {{ }} reaching a file via the render fallback: real in code,
  but refuted end to end. {{ 1/0 }} exits 1 with no artifact — the
  unresolved-template guard from Stop unresolved templates before they reach a tool (#153) #439 catches it first.
• A "nondeterministic condition operator" in 04 — the source flipping
  between > and < mid-run. That was my own doing: a mutation-testing agent
  was concurrently applying and reverting exactly that edit to that file.
  Contamination from parallel red-teaming, not a defect.

Path traversal via -i out_dir=../escape is real but I judge it by design:
this is a local CLI and the operator supplies the path. Flagging, not fixing.